BA: Бизнес-процессы FoodTracker

WarningОграничение публичной документации

В открытом доступе представлена демонстрационная версия метода. В настоящей публичной документации отображены не все шаги, технические сценарии и приватные эндпоинты для системы цифровых симуляторов бизнес-процессов.

• Полная спецификация метода: Будет доступна только во внутреннем контуре разработки (Confluence / Swagger Enterprise).

1 B2B-интеграция с партнерскими магазинами (Внешнее API)

Процесс регламентирует автоматическое зачисление продуктов на баланс пользователя напрямую из торговых сетей в момент оплаты или доставки заказа через открытый программный интерфейс (API).

1.1 Спецификация процесса

• Триггер: Закрытие чека или смена статуса заказа на «Доставлено» во внешней системе партнерского магазина.
• Владелец процесса: Ведущий системный аналитик (Интеграции и B2B-контур).
• Бизнес-цель: Обеспечить мгновенную автоматическую синхронизацию покупок пользователя с его цифровым холодильником без необходимости сканирования бумажных чеков.

1.2 Пошаговый алгоритм выполнения

1. Шаг 1 (Внешняя система): Информационная система магазина генерирует HTTP POST запрос на специальный шлюз, передавая сформированный Бизнес-JSON со списком товаров.
2. Шаг 2 и Шлюз «Токен OK?» (Контур интеграции / Go): API Gateway проверяет партнерский статический Auth Token в Header запроса. При неверном или отсутствующем токене система возвращает ошибку HTTP 401 Unauthorized и обрывает флоу.
3. Шаг 3 и Шлюз «DTO OK?» (Контур интеграции): Прошедший авторизацию JSON-пакет валидируется на соответствие жесткой схеме данных. При обнаружении несоответствия типов (например, текст вместо веса) шлюз возвращает HTTP 400 Bad Request.
4. Шаг 8 (Контур холодильника): Валидный массив продуктов передается в PostgreSQL, где выполняется быстрый пакетный INSERT. Продукты мгновенно падают на баланс пользователя со статусом В наличии.
5. Асинхронные выходы: • Сквозной аудит: Факт успешной B2B-партнерской транзакции отправляется в ClickHouse (Шаг 12-13) с тегом роли QA_Automation или System для построения сквозных карт Process Mining. • Подтверждение (Шаг 9): Бэкенд Go генерирует успешный ответ HTTP 200 OK и инициирует асинхронный вызов Webhook-эндпоинта магазина.
6. Шаг 10 (Внешняя система): Магазин принимает входящий POST Webhook (Confirmation), фиксируя успешное завершение распределенной синхронизации.

1.3 Бизнес-правила и SLA интеграционного контура

• Ограничение на размер пакета: Максимальный объем JSON-массива от внешнего магазина за один вызов — не более 500 позиций товаров (защита от DDOS/OOM).
• Таймаут Webhook-подтверждения: Контур интеграции ожидает ответ от сервера магазина на шаге 10 в течение 3000 мс. При таймауте задача отправляется в очередь на повтор (Retry Policy: 3 попытки с интервалом в 5 минут), а в логи пишется статус Timeout_Warning.

2 Автоматическое распознавание медиаданных (OCR и Voice/Whisper)

Процесс обеспечивает бесшовную оцифровку чеков и голосовых команд пользователя, сводя разнородные входящие медиапотоки к единым методам обработки на бэкенде.

2.1 1. Спецификация процесса

• Триггер: Нажатие пользователем кнопки «Сканировать чек» или «Голосовой ввод» на интерфейсе Flutter.
• Владелец процесса: Архитектор ИИ-решений / Ведущий backend-разработчик.
• Бизнес-цель: Автоматически извлечь перечень продуктов, их весовые и ценовые параметры из сырых файлов/потоков, минимизируя время ручного набора.

2.2 2. Пошаговый алгоритм выполнения

1. Шаг 1 (UI Интерфейс): Пользователь захватывает изображение чека или наговаривает аудиопоток. Приложение Flutter стримит данные на бэкенд.
2. Шлюз определения типа обработки (Контур оркестрации / Go): Система маршрутизирует запрос на один из двух универсальных методов: • Пакетный метод (Шаг 2): Применяется для статичных снимков чеков. Файл целиком загружается в S3-хранилище MinIO, а бэкенд регистрирует задачу. • Стрим-метод (Шаг 3): Применяется для потокового аудиоввода через высокопроизводительное gRPC / HTTP/2 соединение.
3. Шлюз «Медиа?» (Контур ИИ / FastAPI): Запрос передается в вычислительный слой ИИ: • Ветка «Картинка»: Движок OCR (Шаг 4а) обрабатывает изображение и на выходе сразу формирует структурированный JSON с распознанной матрицей продуктов. • Ветка «Голос»: Движок Whisper (Шаг 4б) транскрибирует аудио в сырую текстовую строку. Строка немедленно передается в Семантический парсер (Шаг 4в), который с помощью NLP-моделей выделяет сущности (название, вес, количество) и упаковывает их в финальный JSON.
4. Шаг 5 (Контур оркестрации): Бэкенд на Go принимает нормализованный Бизнес-JSON, формирует итоговый DTO-пакет, обновляет инвентарь пользователя в PostgreSQL (HTTP 200 Success) и асинхронно пушит событие в ClickHouse (Шаг 12-13) для Process Mining.

3 Процесс снабжения (Пополнение запасов)

Процесс отвечает за первичный ввод ресурсов, валидацию входящих пакетов данных и постановку продуктов на баланс системы.

3.1 1. Спецификация процесса

• Триггер: Завершение пользователем реальной закупки продуктов и открытие экрана ввода в приложении Flutter.
• Владелец процесса: Продуктовый аналитик (Product Owner).
• Бизнес-цель: Корректно оприходовать входящую партию еды, зафиксировав финансовые (Цена) и объемные (Вес, Количество) параметры для DWH.

3.2 2. Пошаговый алгоритм выполнения

1. Шаг 1 (UI Интерфейс): Пользователь вносит в форму на Flutter-клиенте массив данных: наименования продуктов, их чистый вес в граммах и стоимость. Нажимает кнопку «Сохранить».
2. Шаг 2-3 (Контур закупок / Бэкенд Go): Бэкенд принимает DTO-пакет и запускает техническую валидацию (проверка типов данных, лимитов, отсутствия пустых строк или отрицательных чисел).
3. Шлюз «Данные OK?»: • Ветка «Нет»: Запрос отклоняется, бэкенд возвращает ошибку HTTP 400 Bad Request. Интерфейс Flutter отображает окно ошибки валидации. Процесс прерывается. • Ветка «Да»: Запрос передается на уровень ниже — в Контур холодильника.
4. Шаг 8 (Контур холодильника / СУБД): Бэкенд выполняет транзакцию INSERT в операционную базу данных PostgreSQL. Продуктам присваивается статус В наличии, баланс холодильника обновляется.
5. Шаг 12-13 (Сквозной аудит / ClickHouse): Одновременно с успешным ответом пользователю (HTTP 201 Created), бэкенд асинхронно отправляет событие снабжения в шину данных. Оно пишется в ClickHouse как стартовая точка журнала событий (Event Log) для Process Mining.

4 Процесс трансформации (Готовка)

Процесс описывает нелинейное изменение состояний, при котором сырые ингредиенты списываются ради генерации абсолютно новой кулинарной сущности с кастомным именем.

4.1 1. Спецификация процесса

• Триггер: Выбор пользователем рецепта или набора продуктов на экране «Кухня» и нажатие кнопки «Приготовить».
• Владелец процесса: Системный аналитик бэкенда.
• Бизнес-цель: Проверить доступность объемов, списать сырье и зафиксировать продуктовую родословную (Data Lineage) нового блюда.

4.2 2. Пошаговый алгоритм выполнения

1. Шаг 1 (UI Интерфейс): Пользователь выбирает из списка доступных остатков нужные ингредиенты, указывает их вес для списания, вводит текстовое название будущего блюда (например, «Домашний борщ») и отправляет запрос.
2. Шаг 2-3 (Контур готовки / Бэкенд Go): Бэкенд валидирует структуру входящего Go-DTO.
3. Шлюз «Данные OK?» и Шлюз «Без мата?»: • Бэкенд последовательно проверяет корректность ID продуктов, а затем прогоняет кастомное имя блюда через встроенную службу цензуры. • Если структура нарушена или в названии обнаружен нецензурный текст/мат — флоу заворачивает на ошибку HTTP 400. Пользователь получает отказ.
4. Шлюз «Вес есть?» (Контур холодильника): Система делает SELECT из PostgreSQL и проверяет, физически ли хватает в холодильнике указанного веса ингредиентов. Если веса недостаточно (например, в базе 200г мяса, а пользователь указал списание 500г из-за бага синхронизации фронтенда) — процесс прерывается с ошибкой «Недостаток веса».
5. Шаг 6 (Списание): Если проверка пройдена, бэкенд уменьшает вес исходных продуктов в БД.
6. Шаг 8 (Регистрация): Бэкенд генерирует новый уникальный Case ID и записывает в PostgreSQL новую сущность — готовое блюдо со статусом В наличии.
7. Фоновый пуш (Сквозной аудит): Бэкенд шлет асинхронный сигнал в ClickHouse. В Event Log фиксируется факт трансформации сырья в готовый продукт для анализа эффективности кулинарных конверсий.

5 Процесс утилизации (Расход запасов)

Финальный этап жизни любого продукта в системе, закрывающий его уникальный идентификатор в Process Mining.

5.1 Спецификация процесса

• Триггер: Действие пользователя на экране остатков («Я съел это» или «Продукт испортился, выкидываю»).
• Владелец процесса: Продуктовый маркетолог / Аналитик потерь.
• Бизнес-цель: Зафиксировать тип расхода запасов для формирования воронки полезного использования.

5.2 Пошаговый алгоритм выполнения

1. Шаг 1 (UI Интерфейс): Пользователь выбирает позицию в холодильнике, указывает вес расхода и выбирает эндпоинт списания.
2. Шаг 2-3 и Шлюзы валидации (Контур утилизации): Бэкенд проверяет валидность запроса. При успехе флоу доходит до шлюза «Тип?».
3. Шлюз «Тип?» (Маршрутизация расхода): • Ветка «Потребление» (Эндпоинт 6а): Запускается, если еда съедена. Вес продукта в PostgreSQL уменьшается на указанную дельту. Это фиксируется как полезный расход. • Ветка «В мусорку» (Эндпоинт 6б): Запускается при порче еды. Вес уменьшается, но транзакция помечается как операционный убыток.
4. Шаг 8 (Контур холодильника): В базе данных обновляется остаток строки. Если после вычитания дельты вес продукта стал равен 0.0, запись получает финальный статус Утилизирован.
5. Шаг 12-13 (Сквозной аудит): Факт частичного или полного списания отправляется в ClickHouse.

5.3 Бизнес-правила и ограничения (Важно для аналитиков)

• Запрет отрицательного баланса: Ни один эндпоинт не имеет права переводить поле weight в значение меньше нуля.
• Правило закрытия трассы (Case ID): Case ID продукта считается открытым и доступным для текущего майнинга в PM4Py до тех пор, пока его совокупный вес в Контуре холодильника больше нуля. Запись со статусом Утилизирован переводится алгоритмами в категорию архивного лога.